The present invention is concerned with the field of methods for communication between software modules and more particularly software buses.
Information processing devices work under the control of an operating system. These operating systems are multitask and enable the scheduling of a plurality of software modules. These software modules may be of several types according to the scheduler that organises the multitasking and the possibilities of a hierarchy of modules.
Historically, operating systems enable the scheduling of processes. A process is defined as a software module having its own control and its own memory space. The scheduling of processes is typically performed today in a pre-emptive manner. That is to say the scheduler decides in an arbitrary fashion on the times to switch context between the processes. The context of the current process, typically the content of memory caches, the content of the processor registers and the pointer instructing the control, is then saved. Another process that is waiting is selected and the context thereof is restored. It can then continue its execution.
Context switching is a relatively complex process. The need to drive lighter parallel software modules has arisen. The concept of threads has therefore been created. Typically, a set of threads is scheduled in a common memory space, it is generally a case of one process.
In some cases, it is possible to implement a supplementary level and to schedule a set of tasks actually within a thread. The scheduling may then be pre-emptive or not. The other scheduling family, cooperate scheduling, takes place at the time of specific system calls where the task passes control explicitly to the scheduler. The main difference relates to the fact that, in such scheduling, a task entering an infinite loop may prevent the system from taking over and block the complete system. The advantage being that, since a task cannot be interrupted at any time, it is not necessary to protect the resources shared by mutual exclusion (mutex) mechanisms.
We shall therefore consider the software executed on an information processing device as one or more processes, each process being able itself to consist of one or more threads, each thread being able to consist of one or more tasks. The scheduling of the processes and threads will be considered to be pre-emptive, while the scheduling of the tasks may be pre-emptive or not. We generically use the term software module to designate all these processes, threads and tasks.
This hierarchy of software modules is illustrated by FIG. 1. An information processing device 1.1 can be seen therein. This device enables three processes 1.2, 1.3 and 1.4 to be executed in parallel. These processes are scheduled by the operating system 1.16. The process 1.2 contains several threads 1.5, 1.6, 1.7 and 1.8 executed in parallel, scheduled by the operating system 1.16. The process 1.3 does not contain any threads. The process 1.4 contains a first thread 1.9 and a second thread 1.10. This second thread 1.10 itself contains several tasks 1.11, 1.12 and 1.13 executed in parallel under the control of a scheduler 1.14, itself executed within the thread 1.10. The device has at least one communication port 1.15 affording communication with other devices via a communication network, typically an IP network.
When it is sought to make software modules communicate, solutions dedicated to a given level of parallelism are found in the prior art. The main technologies are dedicated to communication between processes. Message queues, UNIX sockets for communication between processes of the same device and INET sockets for communication between processes situated on remote devices connected to an IP (Internet Protocol) network can be cited. Software buses exist, such as the D-Bus, which is a system for communication between processes. It is not suitable for software modules neither such as simple tasks nor for threads nor for communication between machines.
The invention aims to propose a communication system or software bus that affords communication between software modules. This communication occurs in a machine and between machines and indifferently functions for the software module, whether it is a case of a process, a thread or a simple task. The communication is based on mechanisms adapted to the multitask level at which the sender and receiver software modules operate. It is based on a hierarchical architecture, phases of discovery and of recording of the various software modules having to communicate via the bus.